Web application development platform with relationship modeling

ABSTRACT

A system and method for dynamically creating web applications from data is described. Simple data is transformed into a declarative application data model that is then parsed by a server and compiled into a functional web application. Application functionality is partly determined by rules applied to web application objects in response to user actions. These rules are triggered by various cues, including user actions and relationships among objects in the web applications. A web application is considered an n-dimensional problem space, and relationships among application objects can be modeled using set theory. The status of a particular relationship among objects and user actions can trigger specific application behavior. Additionally application behavior can be triggered in other ways, like conditions in arbitrary scripts or combinations of multiple triggers combined using logical connectives.

PRIORITY APPLICATIONS

This is a continuation patent application drawing priority from U.S.patent application Ser. No. 13/973,888; filed Aug. 22, 2013.

This present patent application draws priority from the referencedpatent application. The entire disclosure of the referenced patentapplication is considered part of the disclosure of the presentapplication and is hereby incorporated by reference herein in itsentirety.

TECHNICAL FIELD

This patent application relates to computer-implemented software andnetworked systems, according to one embodiment, and more specifically toa system and method for web application development with relationshipmodeling.

BACKGROUND

With the maturation of web technology, more functionality is beingdelivered to users via web applications that run inside browsers. A webapplication can be any piece of functionality that executes in abrowser. Applications that once ran as locally-installed software on adesktop computer are now often accessed remotely from the cloud(remotely hosted internet services) via a web browser. Applications likeGmail and Google Docs are perfect examples. Instead of using aninstalled email client, people use a web browser to access their email.Instead of locally-installed spreadsheet or word processing software,people use a web browser to access Google Docs to create spreadsheetsand word documents online.

The web applications, sometimes called Rich Internet Applications (MA),often leverage web technologies like JavaScript, JavaScript libraries(like jQuery), Ajax, HTML5, CSS3, and others to provide agraphically-rich, responsive interface for a user via a web browser. Webapplications can be simple as well and be composed of more standardHTML, CSS, and JavaScript.

As more and more software is delivered via the web, the need for toolsto enable easy creation of web applications has grown. One tooldeveloped to meet this need is the Google Web Toolkit (GWT). The GWT isa Java to JavaScript compilation tool that leverages professional Javadevelopment and debugging tools to facilitate development of webapplications. It also helps alleviate cross-browser compatibility issuesand performs optimizations on the compiled JavaScript. Basically, GWT isa tool for more easily writing JavaScript applications using customcode. GWT requires developers to write Java code that is compiled intoJavascript. GWT is essentially a Java to JavaScript compiler and isbroadly applicable for creating many kinds of web applications. GWT isnot a declarative application modeling language and has no declarativemechanism for managing rules and relationships among objects anddynamically updating the user interface in response to user actions andselections. GWT also does not transform basic xml data into applicationdata that can be parsed on a server and delivered to users as afully-functional web application. In other words, GWT is a tool thathelps facilitate the creation of JavaScript applications, but GWT doesnot offer the novel elements of the embodiments described and claimedherein.

Many HTML and CSS frameworks have also been constructed to help ease theburden of creating web sites and web applications. These frameworks arebuilding blocks for web development and facilitate building an inventionlike the one described here. However, like GWT, these frameworks are notspecifically designed to rapidly build and update the type ofrules-based applications described herein. Specifically the frameworksdo not provide a declarative application modeling language with supportfor rules that dynamically manage the web application interface based ona user's selections.

Additionally, a particular class of applications that depend on managingcomplex product relationships and intricate internal logic, often calledconfigurators, has conventionally been delivered as client/serverapplications where the logic is executed on the server. Theclient/server interaction introduces latency and processing delaysbecause the client has to send a request to the server for every actiontaken on the client and then wait for the response from the server.

SUMMARY OF THE INVENTION

The various embodiments of this invention provide an applicationdevelopment platform for creating, deploying, and updating webapplications. The embodiments take advantage of advances inclient-side/browser functionality to deliver applications that runprimarily on the client, which improves responsiveness and performance.

The platform of an example embodiment uses a declarative applicationlanguage to describe web application data and functionality. Using adeclarative language simplifies application creation and maintenance.

Functionality that falls outside the bounds of the declarativeapplication language can be provided via custom code. The exampleembodiment offers hooks for external code to be triggered based onevents in the web application, and also provides an ApplicationProgramming Interface (API) that external code can use to interact withthe web application.

The declarative application data is compiled into ready-to-serve webapplication content that can be cached and delivered to user browsersreliably and scalably. Using pre-compiled, cached content minimizesserver load by only compiling the web application once, when theapplication is deployed to the server, and not compiling the applicationevery time it is requested by a user. Pre-compiling the content resultsin minimal server processing to service requests and also enables use ofcaches and global content delivery networks.

Simple, base data is transformed into declarative application databefore being deployed to the platform server. The intermediatetransformation process provides several of advantages:

-   -   It keeps base data simple and shields application managers from        any data complexity they do not need access to.    -   It allows validation/error-checking on base data in the exact        format the application manager is comfortable with.    -   It allows data and transformations to be reused and repurposed        to leverage existing resources and improve development        efficiency.

Some of the options for data and transformation reuse include:

-   -   Using multiple base datasets with a single transformation to        create multiple web applications.    -   Using a single base dataset with multiple transformations to        create multiple web applications.

Datasets and transformations can be mixed and matched in many ways tomaximize reuse of existing assets. Datasets and transformations can alsobe dynamically/automatically created and invoked to generate webapplications without any manual intervention.

Embedding web applications into client web pages is primarily performedby the platform server, which makes embedding very simple for a client.A client simply inserts a token into their host page and provides theURL of their host page to the platform. The platform server managesretrieving the host page, embedding the web application into the hostpage, and delivering the resulting complete web page.

The web application can also be integrated with various third partysystems, like e-commerce platforms, via custom scripts that are includedin the embedding process.

To enable web applications with complex product compatibilities andintricate business logic, the described example embodiment supportsseveral mechanisms for specifying and enforcing relationships amongapplication objects, including: position-based relationships,script-based relationships, and Boolean combinations of relationships(grouping relationships via logical operators like “and”, “or”, “not”,etc.). These relationships are structured to trigger appropriate actions(application behavior) in response to user selections, gestures, orbehavior.

An action in combination with an action trigger can be considered arule. Rules can be specified to perform certain actions under certainconditions. These actions can include: showing and hiding applicationobjects, selecting and deselecting application objects, showing messagedialogs, adjusting the application UI (e.g. changing a product view ormoving to a new selection area), etc.

A key feature of the described example embodiment is the maintenance ofapplication state in a state identifier (which can easily be expressedin a URL—a “stateful URL”). Web applications are not dependent onsequential application of operations in order to arrive at the correctstate. A web application can accurately parse and represent its currentstate from the data contained in a single URL. Using stateful URLs ofcourse does not prevent the system from using other state representationtechniques. State identifiers enable state caching, transmission ofstate information among web applications, and social/sharingfunctionality

BRIEF DESCRIPTION OF THE DRAWINGS

The various embodiments are illustrated by way of example, and not byway of limitation, in the figures of the accompanying drawings in which:

FIG. 1 illustrates a conceptual overview of how data gets converted intoa functional web application;

FIG. 2 illustrates a more detailed overview of the components andprocess involved in creating a web application from data;

FIG. 3 illustrates how an application manager can update the applicationdata and deploy those changes to the web application server;

FIG. 4 illustrates how a single dataset can be run through differenttransforms to yield different web applications;

FIG. 5 illustrates how multiple datasets can be run through a singletransform to yield different web applications;

FIG. 6 illustrates the sequence of steps involved in embedding a webapplication into a client host HTML page;

FIG. 7 illustrates how a single web application can be embedded intomultiple host HTML pages;

FIG. 8 illustrates an overview of position-based set operations used inrelationship modeling;

FIG. 9 illustrates an abstract, conceptual example for understandingposition-based relationship modeling;

FIG. 10 illustrates a concrete example for understanding position-basedrelationship modeling;

FIG. 11 illustrates an application nesting example used in the exampleshown in FIG. 12;

FIG. 12 illustrates the sequence of steps involved in just-in-timedownloading;

FIG. 13 is a processing flow chart illustrating an example embodiment ofa method as described herein;

FIG. 14 shows a diagrammatic representation of machine in the exampleform of a computer system within which a set of instructions whenexecuted may cause the machine to perform any one or more of themethodologies discussed herein; and

FIG. 15 illustrates a network environment in which an example embodimentcan operate.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the various embodiments. It will be evident, however,to one of ordinary skill in the art that the various embodiments may bepracticed without these specific details.

In the various embodiments described herein, a system and method for webapplication development with relationship modeling are disclosed. Thevarious embodiments provide a system and method for dynamically creatingweb applications from data. The described example embodiment capitalizeson the improved processing power of client computers and improved webtechnologies to provide a solution that is easier to build and updateand is more flexible and more responsive than previous approaches.Simple data is transformed into a declarative application language thatis then parsed by a server and compiled into a functional webapplication. Data from any source can be aggregated into a simplestructured dataset. This simple structured dataset is then processed totransform it into a declarative application format. This applicationdata is then compiled into the HTML, JavaScript, and web componentsneeded to deliver a fully-functional web application to a requestingbrowser. The application is responsive to user actions and dynamicallyupdates its interface as a user interacts with the application. The userinterface updates are based on: user actions, directives contained inthe declarative application language, and relationships among objectsspecified via the modeling systems described.

DEFINITIONS

Application Client (also Client)—a person, group or entity that uses thedescribed web application platform to provide web applications for theirusers. Not to be confused with “client” when used in the context ofclient/server computing architecture.

Application Data—Data that conforms to the schema defined by theapplication data language. Application data is data that is ready to becompiled into a web application by a server.

Application Developer (also Developer)—a person, group or entity thatuses the described web application development platform to create webapplications on behalf of an Application Client.

Application Manager (also Manager)—a person, group or entity that usesthe described web application development platform to manage andmaintain web applications on behalf of an Application Client.

Application Web Page—the complete HTML page that includes the Host HTMLPage as well as the embedded web application and all resources requiredby the web application.

Base Data—simple, structured data that is transformed into ApplicationData.

Host HTML Page—the HTML into which a web application will be embedded.

Resources—Any files, code, data, information used by the platform toenable its functioning.

Web Application—A set of web resources that, when combined with a HostHTML Page, provide the desired web functionality.

Description of an Example Embodiment of the Declarative ApplicationLanguage

A declarative web application language simplifies applicationdevelopment by allowing web application developers to createapplications by defining what the applications do, not how they do it.Similar to creating an HTML web page, the declarative web applicationlanguage lets developers build applications by specifying the data andbehavior of a web application using declarative tags. A completelycustom web application can be created without any custom coding at all.

A declarative application file could be as simple as:

<application> <app_id> <client_id>clientA</client_id><model_id>modelA</client_id> </app_id> <flow><question_pool /></flow><ui> <basic_ui> </ui> </application>

This application simply serves as a shell into which other applicationscan be nested. What is important is that there is no code involved, justa simple, declarative model of the application. The same declarativeapproach can be used to create far more elaborate applications. Anexample of a more complex application is shown below in Appendix A.

Customization

The platform of an example embodiment also offers many hooks triggeredby events in the application so that any functionality not provided bythe existing language tag set can be created with custom code. Theplatform also provides a JavaScript API accessible to externalJavaScript.

Pre-Compilation

When application data files are sent to the platform server, the serverparses the declarative data and compiles it into serialized, optimizedweb applications that are ready to be embedded into client web pages andserved to user browsers. Because the user interaction with theapplication is all managed on the browser, the server only needs toprovide the browser with static web application content. The platformserver does not need to manage state, sessions, cookies, or deliver anydynamic application content.

Using static, pre-compiled resources allows the platform to run withminimal server load. Additionally utilizing static, pre-compiledresources allows the platform to leverage proxy caches and contentdelivery networks for high scalability and resiliency.

Data Transformations

Overview

Base data is transformed into declarative application data before beinguploaded or deployed to the platform server. Using a data transformationto transform simple, base data into the declarative application languageoffers ease-of-use and flexibility. The base data can be formatted to aparticular client's needs and nomenclature. It can contain only the datathat a client wants to manage. All of the other declarative applicationtags/elements can be hidden inside the data transformation. The clientcan be shielded from any complicated, confusing, or unneededinformation. Providing a client-specific data format offers ease-of-usefor the client by eliminating any unnecessary information from the basedata and by tailoring the names of the data elements to exactly what theclient is comfortable with. Offering the client a simple data formatcontaining only client-relevant information means clients can morequickly and easily manage their data and business logic. It also meansthat business managers and domain experts can update their own webapplications as business logic changes, and the need for IT middlemen iseliminated, resulting in huge cost savings.

The base data can be assembled from any source, or even multiplesources. It can be pulled from spreadsheets, databases, flat files,entered manually, etc. The base data is a collection of data that is ina format that a data transformation can correctly process. Base datasetshave schema that define their structure. A schema can be unique for aparticular dataset, or one schema can be more general and applicable tomany datasets.

FIG. 1 highlights a simple overview of the transformation process. BaseData is pulled into the Platform and transformed and compiled into a WebApplication.

FIG. 2 shows a detailed view of the process in FIG. 1. Base Data ispulled into the Web Application Platform where it is transformed intoApplication Data. The Application Data is then deployed and compiledinto a web Application Object. On request from a Browser, the webApplication Object is embedded into the Host HTML and delivered to therequesting Browser. The requesting Browser retrieves all referencedresources and loads the Web Page, which includes fetching all relatedpage resources, like CSS and JavaScript, and initializing theApplication Object.

In one embodiment of the invention, the base data is described inExtensible Markup Language (XML) and linked with XML Schema Definition(XSD) files to provide validation tools to application managers anddevelopers. Validation tools make it easier for managers and developersto manage data. The base data is then transformed into application datausing Extensible Stylesheet Language (XSL) tools.

This base data is transformed into the application data languageunderstood by the platform server. Converting base data into afully-functional web application ready for delivery to browsers iscalled “deploying”. The act of deploying is automated and can betriggered by a client or web application developer with a single clickof a button on a web page or a single call to the platform web service.Deploying new web applications can be automated or scheduled as well.

FIG. 3 depicts the deployment process. An Application Manager orDeveloper first updates the Application Resources by making changes tothe base data or transforms. Then the manager sends a request to theDeploy Server to trigger the deployment process. The Deploy Serverfetches the updated Application Resources and executes the datatransformation, which results in new Application Data files. TheseApplication Data files are uploaded to the Web Application Server wherethey are compiled, optimized, and stored as Web Application Objects,ready for embedding into a web page.

Transformation Options

The mechanism of transforming base data into application data enablesdata and transformations to be mixed and matched in various ways toprovide for reuse and repurposing of existing data and transformations.

Single Dataset/Multiple Transformations

For example, a single base dataset can be transformed in multiple waysto create multiple, different web applications. A use case might be aproduct manufacturer who wants to use the same data to create a webapplication for internal employees and a web application for externalresellers. The same data can be used with two different transformationsto create the two separate applications. Being able to reuse the singledataset means an application manager only needs to manage data in asingle place, which is more efficient and eliminates datasynchronization problems.

A single dataset can also be used with multiple transformations tocreate multiple applications based on the same data to use for ABtesting. Clients can then test multiple versions of an application todetermine which functionality is more effective.

A dataset can also be channeled through multiple separatetransformations (a transformation pipeline) to arrive at the finalapplication data file. In other words base data can be transformed bytransform 1; the output of transform 1 is transformed by transform 2;the output of transform 2 is transformed by transform 3; the output oftransform 3 is the application data. Any number of transformations canoccur between the base data and the resultant application data.

FIG. 4 diagrams the process of transforming a single dataset intomultiple applications.

Base Dataset 1 is transformed via Transform 1 to yield Application Data1. Application Data 1 is then deployed and embedded to produce WebApplication 1.

Base Dataset 1 is transformed via Transform 2 to yield Application Data2. Application Data 2 is then deployed and embedded to produce WebApplication 2.

Multiple Datasets/Single Transformation

Another example is using multiple datasets with a single transformation.In this way, multiple web applications can be created that exhibitcommon functionality but use different underlying data. A use case mightbe a retailer who wants to offer a product line with many products, forexample a furniture maker who sells couches and chairs. The retailerwould like end users to be able to view separate web applications foreach of the products, couches and chairs. Since the applicationfunctionality is common to both applications, the retailer would like tore-use the same functionality for both applications (i.e. bothapplications show images of the product and allow users to selectfabrics and trim pillows, etc.). To do so, the retailer would like tocreate the two datasets, one for each product, and have a singletransformation generate the two different applications. The singletransformation would turn the base data for couches and the base datafor chairs into two separate web applications that behave similarly butpresent the end user with different options that reflect the differentunderlying datasets.

FIG. 5 diagrams the transformation of multiple datasets into multipleapplications via a single transform.

Base Dataset 1 is transformed via Transform 1 to yield Application Data1. Application Data 1 is then deployed and embedded to produce WebApplication 1.

Base Dataset 2 is transformed via Transform 1 to yield Application Data2. Application Data 2 is then deployed and embedded to produce WebApplication 2.

Automatic Applications

Creation of a web application using the described platform is done byuploading declarative application data to the platform server. How thisapplication data is generated is irrelevant to the server. Theapplication data can be generated manually, via a data transformationpipeline, or generated via a scheduled automated process thatdynamically creates application data files without any manualintervention.

Simple Embedding/Integration

The technique utilized by the described web application platform enablessimple integration with client web sites and provides flexibility inallowing web applications to be repurposed for use in multiple webpages, even with different behavior defined by each web page.Conventionally, embedding external web applications into a web page (or“host page”, the page into which the web application gets embedded)requires that JavaScript or HTML tags be added directly to the web page.This approach introduces the potential for error in adding the requiredelements and also introduces a maintenance burden if the externalapplication provider needs to update code or tags. Often the externalapplication provider requests that all users of their system make manualupdates to the host pages using their applications, which is obviously ahassle for both the application provider and its users.

Rather than require clients to insert custom JavaScript or tags intotheir host pages, this example embodiment moves the onus of integrationalmost completely to the platform, which simplifies client integrationand removes the maintenance burden from clients. All clients have to doto embed a web application into a web page is add a simple HTML tag totheir host page at the location where the web application should beembedded.

For example, in the sample host html page below the “<!-- app.embed -->”tag tells the platform server where to embed the web application:

<html> <body> Embed application here: <!-- app.embed --> </body> </html>

A key to this process is delivering the web application directly fromthe web application platform and not from the client web site. As shownin FIG. 6, to deliver a complete web application a Browser requests aparticular Web Page from the Web Application Server. The Server then:

-   -   fetches the client Host HTML from the client Host HTML Server,    -   embeds the web Application Object into the Host HTML, including        adding any necessary scripts, tags, css, etc. required for        proper functioning of the web application,    -   delivers the complete Application Web Page to the requesting        browser.

This finalized application web page can be cached to eliminate the needto fetch the client host page and re-create the application web page onevery web application request.

Cookies and HTTP request headers can be forwarded along to the clienthost html server when fetching the client host HTML page.

Additionally the URL of the web page can be masked via reverse proxy,custom subdomains, or alternative techniques to make the URL match thatof the client web site or domain. Reverse proxy is a mechanism fordelivering content from a remote server via an intermediate server sothat the content appears as if it originated from the intermediateserver.

This approach enables very simple embedding for the client, but alsooffers flexibility in reusing the same web application in multiple webpages. A complete application web page includes the host HTML, the webapplication, and can also include different CSS for styling, differentscripts for different functionality, different back-end integration,like connecting with different e-commerce systems, etc. A completeapplication web page contains all information that is used in displayingand executing a web application in a client browser.

As shown in FIG. 7, a single web application can be embedded in multipleweb pages to yield multiple web applications with potentially differentbehavior, styling, integration with third party systems, etc. In FIG. 7,Application Object 1 is embedded into Host HTML 1. Host HTML 1 includesspecific styling information, CSS 1, and specific functionality viaCustom JavaScript 1. When combined with the Application Object theresulting Web Application 1 has styling and functionality defined by CSS1 and Custom JavaScript 1. This example with CSS and JavaScript issimply illustrative; other web resources can be included in the web pageto affect the behavior of the web application. Also Custom JavaScript 1can include multiple JavaScript files from various sources.

FIG. 7 also shows Application Object 1 embedded into different hostHTML, Host HTML 2. Host HTML 2 uses different resources, CSS 2 andCustom JavaScript 2, to apply different styling and behavior toApplication Object 1, resulting in an entirely different webapplication, Web Application 2.

Web Page 1 and Web Page 2 can use the same application object to fulfillvarious needs. The key benefit is the ability to reuse and repurposeexisting data and application functionality, which saves time andminimizes data maintenance problems.

For example a product manufacturer might have a main web site with a webapplication for direct access by customers. The manufacturer might haveresellers who also want to offer customers the ability to interact withthe same web application on the reseller web site. The embeddingtechnique described above allows a single web application to be embeddedin both the manufacturer main site and the reseller site, each withdifferent styling and connections to different e-commerce systems.

Another key element of this approach is ease of maintenance. Any changesto the embedding approach can be done once in a centralized location onthe web application platform server and disseminated globally andinstantly to all web applications on the platform. The need for a changemight occur if the application platform changes its preferredsocial/sharing or analytics code or any other change affecting how anapplication is embedded into host HTML. If the embedding were managed onthe clients' servers, any changes would need to be propagated separatelyto each client's host page and would entail a large manual updatingeffort.

Integration with third party systems, like e-commerce or CRM software,can also be managed via the web context (or application web page), whichconsists of the host HTML page, the embedded web application, and allincluded web resources. A web application can leverage integrationscripts or functionality provided in its web context to communicate withthird party systems. This approach also allows a single web application,when used in multiple contexts, to integrate with different third partysystems. For example the same web application can be used in amanufacturer web page as well as that manufacturer's reseller's webpages, and can integrate with different e-commerce systems in each case.

Relationship Modeling

Applications that manage complex product compatibilities and complicatedinternal logic have a special need to be able to model relationshipsamong application elements in a simple, easy-to-manage format.Applications with such needs include: configuration, troubleshooting,diagnostics, bundling, guided selling, data navigation, sales quotegeneration, expertise automation, recommendation engines,customization/design, personalization, etc., basically any applicationthat provides logical direction or guidance to a user based on userselections.

Such applications continually evolve as the underlying business logicchanges. Maybe new parts or products are introduced, fabrication ruleschange, retailer discounts are updated. Being able to accommodate thecontinually evolving business logic that forms the foundation of theseapplications is critical. Web applications built with this exampleembodiment will be updated regularly and often by people without anyspecialized, technical knowledge. The platform provides a simple,intuitive approach that lets even non-technical users manage and updatetheir application business logic.

Additionally this web application development platform needs toaccommodate applications as varied as custom bike saddle builders todata center configurators, wine pairing recommendation tools to onlineevent planners. The relationship modeling system needs to managerelationships for a wide spectrum of applications and functionality.

To provide the required simplicity and flexibility, this exampleembodiment offers several mechanisms for modeling the business logicthat underlies web applications.

User Selections

As a user interacts with a web application, the user's actions arerecorded as “selections”. These selections can be used to update theapplication state based on internal logic specified in the webapplication. User selections can be treated as a position (or positions)and used in position-based modeling described below. User selections canalso be exposed to custom scripts for use in script-based modeling, alsodescribed below.

Rules/Action Triggers

To reflect the business logic specified by clients in the underlyingdata and transformations, the platform provides a mechanism to updatethe state of the web application based on user selections and userbehavior. The application state can be updated via actions. Actions canbe triggered based on events or input that occur in the web application.An action is any behavior necessary to provide the desired webapplication functionality. Actions can include: showing or hidingapplication objects, selecting or deselecting application objects,showing a message dialog, or any other application behavior.

These actions can be triggered in a number of different ways, outlinedbelow. The combination of a given action with a given action trigger canbe considered a “rule”. Rules can have explicit or implicit actiontargets. An action target is the application object that is therecipient of the behavior specified by a given action.

For example, a rule could declaratively be specified as follows:

<rule> <action><select /></action> <trigger> <on_update> <match><object_id>objectA</object_id> </match> </on_update > </trigger><targets> <object_id>objectB</object_id> </targets> </rule>

This rule indicates that objectB (defined as the target of the rule)should be selected (defined in the rule action) if, when the applicationupdates its state (defined in the trigger), obj ectA is included in theuser's selections (objectA “matches” the user's selections via thedefault “is included” set comparison—more on set comparisons below). Theexample embodiment accommodates rule chaining, where the actiontriggered in one rule can in turn trigger another action, which in turntriggers another, etc.

Position-Based

Position-based relationship modeling derives from the insight that allelements/objects in a web application can be construed as comprising ann-dimensional problem space. Each object in a web application is aposition within a dimension. Dimensions can be nested hierarchically andinfinitely. At the top level a web application can be considered adimension as well as a position (a location inside its own dimension).Inside the application can be any number of other dimensions andpositions, including nested web applications, which are themselvesdimensions within their parent dimension (application). Within thisframework, any set of objects inside a web application can be considereda position and compared against any other set of objects (also aposition) using set theory.

FIG. 8 reviews some of the set operations utilized by the system:includes, is included, intersects, union.

FIG. 9 provides an abstract overview of this problem space. Dimension 1is a global dimension which contains all the positions for a givenapplication. Dimension 1 is also a position, Position 1. Position 1could be nested into a higher dimension. Beneath Dimension 1 are aseries of positions, Position 2-4, which are located directly underneaththe Dimension 1 dimension. Dimension 1 also contains Dimension 2, whichis itself a position, Position 5. Underneath Dimension 2 are twopositions, Position 6-7. Dimension 2 also contains another dimension,Dimension 3, which is a position as well, Position 8. Dimension 3contains two other positions, Positions 9-10.

Using this framework, relationships among application objects can beestablished using simple set theory operators like includes, intersects,union, etc. Based on the configuration in FIG. 9, the followingquestions can be answered. Does Dimension 1 include the set of Position3 and Position 4? Yes. Does the set of Position 3 and Position 9intersect with Position 10? No. Is the set of Position 9 and Position 10included in Position 5? Yes.

FIG. 10 provides a concrete example of this position-based framework.Application 1 is the global application which is both a position and theglobal dimension that contains all other dimensions in that application.Application 1 contains questions, options, solutions, and a nestedapplication, Application 2, which itself contains questions, options,solutions, and nested applications. Questions and applications are bothpositions and dimensions. Options and solutions are just positions asthey do not contain any sub-positions.

FIG. 10 also shows user selections, which are the objects that a userhas selected via interaction with the user interface of the browser.User selections can be represented as a position (or positions) and usedfor comparison purposes. In this case, a user has selected Option 4,Solution 2 and Solution 5. This position, the set of objects comprisedof Option 4, Solution 2 and Solution 5 can be compared using set theoryagainst other sets of positions. For example the set of Solution 2 doesnot include the set of objects in User Selections. However the set ofUser Selections does include Solution 2. Also the set of Solution 2intersects with the set of User Selections. Additionally the set ofOption 2, Option 3, and Option 4 intersects with the set of UserSelections.

These position-based comparisons can be used to trigger specificbehaviors in a web application.

For example to express a product compatibility rule, an applicationdeveloper might specify that a given product option (option B) shouldonly be available to the user if another given option (option A) hasalready been selected. Such a rule can be expressed by saying option Bshould only be visible if option A has been selected by the user. Thetrigger for this rule could be a position-based rule that states: “ifthe user selections include option A, then show option B”.

Such a rule could be written declaratively like this:

<option> <option_id>A</option_id> </option> <option><option_id>B</option_id> <match> <option_id_ref>A</option_id_ref></match> </option>

The above rule is effectively saying “show option B if the set of userselections includes the set of option A”. The action triggers can beevaluated in any order and are activated based on a set comparison withthe current application state. Triggered rules that change applicationstate can cause the set of rules to be re-evaluated for furthertriggers. Such an approach accommodates rule chaining as describedabove.

In code, application objects can be treated as positions by having theapplication objects provide a specific set of functionality. In Java,this functionality can be described as an Interface that might look likethe code below.

public interface Position extends Serializable, Comparable<Position> {public boolean includes(Position otherPosition); public booleanincludes(Position otherPosition, Dimension dimension); public booleanisIncludedIn(Position otherPosition); public boolean intersects(PositionotherPosition); public Position getPosition(Dimension dimension); publicboolean matches(Position otherPosition); ... }

Script-Based

The example embodiment also provides another method for relationshipmodeling: script-based relationship modeling. An action trigger can bespecified as arbitrary custom code. When the action trigger is beingevaluated, the custom code is executed and returns a value indicatingwhether or not the action should be triggered. Allowing arbitrary codeto determine relationships provides unlimited flexibility in whatconditions trigger an action. Application objects can also be markedwith arbitrary custom attributes that can be used in script-basedrelationship evaluation. These custom attributes can be used to enforceattribute-based constraints and provide flags for any other processing.User selections can be retrieved via an API which allows script-basedmodeling against the user selections or against attributes orcharacteristics of the user selections.

Using an example similar to the position-based one above, a script-basedrule could be written like this:

<option> <option_id>A</option_id> <attribute> <name>attr</name><value>11</value> </attribute> </option> <option><option_id>B</option_id> <attribute> <name>attr</name> <value>9</value></attribute> </option> <option> <option_id>C</option_id> <script_match><![CDATA[return selections_api.getAttributeValue(‘attr’) < 10;]]></script_match> </option>

In this example, the script trigger for option C will be triggered whenthe user's selected option has an attribute value of less than 10. Inother words, the script trigger will be triggered when the user hasselected option B but will not be triggered when the user has selectedoption A. This example assumes that options A and B are mutuallyexclusive (i.e. cannot be selected at the same time). Setting up a rulefor mutual exclusion is a capability of the described rule system aswell.

More practically, the example above could be applied in a case where auser is selecting computer hardware components that each has a certainamount of memory. A rule could be specified to show new options to theuser in the case where the user's selected amount of memory exceeds acertain threshold. Alternatively a rule could be specified to eliminatecertain options if the total memory associated with the user'sselections exceeds a certain threshold.

Another example is creating a rule to automatically select a givenoption if a sum total of the user's current selections exceed a certainamount.

Or an application developer might want to use custom logic, based oninteraction with external data, to determine whether a certain productoption is in stock or sold out and not show to the user any productsthat are out of stock.

Combinations

Position-based and script-based triggers can be combined via Booleanoperators: and, or, not, etc. The Boolean operators allow logicalevaluation of multiple action triggers to provide a single result value.The Boolean expressions can be nested. For example:

-   -   (trigger A) or (trigger B and (trigger C or trigger D))

Downloading/Data Partitioning

Just-in-Time Downloading

Application functionality can be spread across multiple nested or linkedsub-applications. Sub-applications are not downloaded by the executingweb application until they might be needed. In other words, webapplications will download any sub-applications that are immediatechildren but not any sub-applications further down the descendant path.For example if Application 1 contains Application 2 which containsApplication 3, upon initialization Application 1 will downloadApplication 2, but will not download Application 3. Only if/whenApplication 2 is actually invoked will Application 3 be downloaded.Using such an approach makes the system very responsive, only pullingdown data that a user is likely to use.

FIG. 11 shows an example of an application nesting configuration.Application 1 has nested applications, Application 2 and Application 3.Application 3 has its own nested application, Application 4.

FIG. 12 shows the sequence of steps involved in just-in-time downloadingfor the example in FIG. 11.

In FIG. 12, a User requests a particular Web Page in their Web Browser.The Web Browser fetches the Web Page and, as part of preparing the webpage for display to the User, retrieves Application 1 from the WebApplication Server. Then the Browser initializes Application 1.Application 2 and Application 3 are immediate children of Application 1,so Application 1 requests Application 2 and Application 3 from the WebApplication Server. The just-in-time downloading for Application 1 isnow complete and the Web Browser displays Application 1 to the User. TheUser then selects Application 2 by interacting with the Web Browser userinterface. The Web Browser transmits this selection event to Application1. Application 2 has already been downloaded, so Application 1initializes Application 2 and displays an updated user interface to theUser. The User now selects Application 3. The Web Browser transmits thisselection event to Application 2. Application 3 has already beendownloaded, so Application 2 initializes Application 3. Application 3sees that it has a child application, Application 4, which has not beendownloaded. Application 3 then downloads Application 4 to be prepared incase the User selects Application 4.

Data Partitioning

Data partitioning enables massive amounts of data to be broken down intomanageable parts (or sub-applications). These manageable parts can bedownloaded as needed by the web application using just-in-timedownloading. Data partitioning combined with just-in-time downloadingmakes it feasible for web application users to traverse vast amounts ofdata in a stepped, organized, and responsive manner.

Application State

State identifiers are strings that contain all information necessary tore-create a particular application state. State identifiers can berepresented in a URL, POST data, flat files, databases, etc. When astate identifier is used inside a URL, the URL is called a stateful URL.The key element is that application state can be represented conciselyand definitively. State identifiers enable state caching, lookahead orpre-caching, and social or sharing features.

State Caching

Because application state is uniquely and definitively represented in astate identifier, a web application can cache the state for a particularstate identifier and not have to redundantly perform the calculationsused to arrive at that state the first time it was accessed by a user.Any rules or relationships used to specify the appropriate state for agiven state identifier only need to be executed once and can then becached, which minimizes processing and enhances performance.

Lookahead/Pre-Caching

Since states can be cached, the described application platform can alsocalculate the state in advance for particular states a user mightaccess. With this technique, application states can be evaluated andcached one time on the server and leveraged by all clients/browsers thatuse that web application. In this way state calculation processing canbe eliminated entirely from the user browser, resulting in betterapplication responsiveness. Web application developers can specify whatkind of caching/lookahead (if any) the system should perform and to whatdepth.

Social/Sharing

Stateful URLs also provide a convenient mechanism for enabling webapplication state sharing. If a user builds a particular productconfiguration in a web application and wants to share it, he can do sosimply by transmitting the appropriate URL to another user. Since allstate is contained in a URL, web application states can also be sharedvia standard sharing mechanisms, like posting to Facebook™, Pinterest™,emailing, bookmarking, etc.

Application Nesting/Linking

Web applications are designed to be nested to an arbitrary depth andalso linked. The distinction between nesting and linking is one of statemaintenance. The mechanism for passing state information among webapplications is state identifiers. In a nested application, all statefor the nested application is reflected in its parent application. In alinked application, the slate is wiped clean, and application state forthe linking application does not reflect the state of the linkedapplication. Although, the act of linking to a linked application caninclude transmitting the linking application's state to the linkedapplication.

Other Features

Post Processing Directives

The declarative application language includes post processing directivesthat can perform general behaviors to generate the desired applicationstate. These post processing directives can include behaviors like:

-   -   Automatically selecting certain application objects, either        based on declarative flags or certain application conditions,        like the existence of only a single application object being        visible/available to a user from a group of possible objects.    -   Automatically adjusting the application UI in some way, like        switching to a different product view in response to a user        action, or changing the visible input area.

Offline Application Cache

A web application can be downloaded, cached, and subsequently runwithout a network connection. The HTML5 “Application Cache” featureeasily enables this functionality via a manifest file.

Platform Versioning

The system is designed to allow different versions of the platform to behosted on different domains or sub-domains, which allows stagedmigration to newer versions. Old versions of the platform can co-existalongside newer versions, and application clients can choose if and whento upgrade to newer versions of the platform. Migration to a newerversion can be done by simply changing a domain name.

Analytics

Analytics are built in to the platform and collect usage data forparticular web applications and global data for all applications inaggregate. Having a view of aggregate analytics for all web applicationsserved by the platform offers a better assessment of global applicationusage by providing more data points.

Installation Options

The platform can run as a cloud-based system with no installationrequirements for application clients, run in a virtual private cloud(VPC) with configurable access via a corporate VPN and/or the Internet,or the system can be locally-installed as a standalone system inside aclient network.

Security

The system can be secured via known security mechanisms like HTTPauthentication/authorization, signed URLs, TLS/SSL, VPN with IPSec andother techniques.

Mobile-Ready

Using standard web technologies like HTML, CSS, and JavaScript enablesweb applications created by the platform to work without modification onmobile devices as well as desktop, laptop, and other conventionaldevices.

FIG. 13 is a processing flow chart illustrating an example embodiment ofa method as described herein.

FIG. 14 illustrates a diagrammatic representation of a machine in theexample form of a computer system 700 within which a set of instructionswhen executed may cause the machine to perform any one or more of themethodologies discussed herein. In alternative embodiments, the machineoperates as a standalone device or may be connected (e.g., networked) toother machines. In a networked deployment, the machine may operate inthe capacity of a server or a client machine in server-client networkenvironment, or as a peer machine in a peer-to-peer (or distributed)network environment. The machine may be a personal computer (PC), atablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), acellular telephone, a web appliance, a network router, switch or bridge,or any machine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. Further,while only a single machine is illustrated, the term “machine” can alsobe taken to include any collection of machines that individually orjointly execute a set (or multiple sets) of instructions to perform anyone or more of the methodologies discussed herein.

The example computer system 700 includes a data processor 702 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU), orboth), a main memory 704 and a static memory 706, which communicate witheach other via a bus 708. The computer system 700 may further include avideo display unit 710 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 700 also includes an inputdevice 712 (e.g., a keyboard), a cursor control device 714 (e.g., amouse), a disk drive unit 716, a signal generation device 718 (e.g., aspeaker) and a network interface device 720.

The disk drive unit 716 includes a machine-readable medium 722 on whichis stored one or more sets of instructions (e.g., software 724)embodying any one or more of the methodologies or functions describedherein. The instructions 724 may also reside, completely or at leastpartially, within the main memory 704, the static memory 706, and/orwithin the processor 702 during execution thereof by the computer system700. The main memory 704 and the processor 702 also may constitutemachine-readable media. The instructions 724 may further be transmittedor received over a network 726 via the network interface device 720.While the machine-readable medium 722 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single non-transitory medium or multiplenon-transitory media (e.g., a centralized or distributed database,and/or associated caches and servers) that store the one or more sets ofinstructions. The term “machine-readable medium” can also be taken toinclude any non-transitory medium that is capable of storing, encodingor carrying a set of instructions for execution by the machine and thatcause the machine to perform any one or more of the methodologies of thevarious embodiments, or that is capable of storing, encoding or carryingdata structures utilized by or associated with such a set ofinstructions. The term “machine-readable medium” can accordingly betaken to include, but not be limited to, solid-state memories, opticalmedia, and magnetic media.

FIG. 15 illustrates a network environment in which an example embodimentcan operate.

The Abstract of the Disclosure is provided to comply with 37 C.F.R.§1.72(b), requiring an abstract that will allow the reader to quicklyascertain the nature of the technical disclosure. It is submitted withthe understanding that it will not be used to interpret or limit thescope or meaning of the claims. In addition, in the foregoing DetailedDescription, it can be seen that various features are grouped togetherin a single embodiment for the purpose of streamlining the disclosure.This method of disclosure is not to be interpreted as reflecting anintention that the claimed embodiments require more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus, the following claims are herebyincorporated into the Detailed Description, with each claim standing onits own as a separate embodiment.

What is claimed is:
 1. A computer-implemented method comprising:receiving one or more base data files at a platform server; transformingthe base data files into one or more application data files, theapplication data files being defined in a declarative applicationmodeling language, the declarative application modeling languagecomprising named data elements arranged in a hierarchical structure, thenames and structure of the named data elements describing an applicationuser interface and behavior, the declarative application modelinglanguage including a structure for managing rules that define in partthe behavior of an application, the rules comprising at least a givenaction and a given action trigger, the given action being automaticallyperformed by the application upon the occurrence of the given actiontrigger, the given action trigger being dynamically evaluated duringexecution of the application; and compiling, by execution of a dataprocessor, the one or more application data files into a correspondingdifferent web application.
 2. The method as claimed in claim 1 whereinthe one or more application data files provide an ApplicationProgramming Interface (API) to enable external code to interface withweb application functionality.
 3. The method as claimed in claim 1wherein base data is transformed into application data.
 4. The method asclaimed in claim 1 wherein multiple base datasets can be input into asingle data transformation to yield multiple, different webapplications.
 5. The method as claimed in claim 1 wherein the webapplication is compiled once and then cached.
 6. The method as claimedin claim 1 wherein base data is automatically generated without manualintervention via an automated process.
 7. The method as claimed in claim1 wherein the one or more application data files are automaticallygenerated without manual intervention via an automated process.
 8. Themethod as claimed in claim 1 wherein the web application compilationprocess is triggered via a single web request, either via a user clickor an automated request.
 9. The method as claimed in claim 1 wherein theplatform server embeds the web application into a client host page byretrieving the client host page, modifying the client host page toinclude all necessary resources required by the web application, andserving the application web page that includes the embedded webapplication.
 10. The method as claimed in claim 1 wherein an applicationweb page is delivered using reverse proxy.
 11. The method as claimed inclaim 1 wherein an application web page is delivered using a clientsubdomain.
 12. The method as claimed in claim 1 wherein the webapplication uses position-based relationship modeling to controlapplication behavior.
 13. The method as claimed in claim 1 wherein theweb application uses script-based relationship modeling to controlapplication behavior.
 14. The method as claimed in claim 1 wherein theweb application uses combinations of position-based and script-basedrelationships combined via logical connectives, including “and”, “or”,and “not”.
 15. The method as claimed in claim 1 wherein the webapplication uses relationships between user selections and applicationobjects to control application behavior.
 16. The method as claimed inclaim 1 wherein the web application uses state identifiers to representapplication state.
 17. The method as claimed in claim 1 wherein the webapplication is partitioned into multiple sub-applications and downloadsthe sub-applications only when needed.
 18. The method as claimed inclaim 1 wherein the platform server can be installed and executed inmultiple network environments, including a cloud system, a virtualprivate cloud, and a private client network.
 19. The method as claimedin claim 1 wherein the platform server can be secured using HypertextTransfer Protocol (HTTP) authentication, Transport Layer Security(TLS)/Secure Sockets Layer (SSL), signed Uniform Resource Locators(URLs), Virtual Private Network (VPN), and Internet Protocol Security(IPsec).
 20. The method as claimed in claim 1 wherein the webapplication functions correctly on mobile devices without anymodifications.